Mobile cellular communication is evolving beyond traditional voice telephony towards more sophisticated services, such as Push-To-Talk (PTT). Similar to conventional walkie-talkie communication, PTT enables mobile communication users to send a voice message to one or more recipients over a mobile phone by simply pushing a key (i.e., PTT button, etc.).
One particular version of PTT, called PTT-over-Cellular (PoC), has started to be implemented in wireless data networks such as GSM/GPRS, EDGE, UMTS and CDMA cellular networks. By using internet protocols (i.e., an internet protocol network), these networks can provide a packet-based data service that enables information to be sent and received across a mobile telephone network. In addition, the use of internet protocols also facilitates PoC through the use of instant connections. That is, information can be sent or received immediately as the need arises, subject to available time slots at the air interface.
PTT, including PoC-based PTT, is half-duplex. That is, all participants typically use a single frequency or channel for both transmission and reception. Either a participant speaks or listens, but not both. This is in contrast to traditional cellular communication that is full-duplex (e.g., like a regular wired phone), in which at least one channel or frequency is assigned to talk, and another separate one is assigned to listen such that both speaking and listening can occur simultaneously.
For audio/video data transmissions, PoC applications require the transmission of signaling packets using a signaling protocol, e.g., Session Initiation Protocol (SIP), and data packets using a data protocol, e.g., Real Time Protocol (RTP). SIP is a signaling protocol for Internet conferencing, telephony, presence, events notification, and instant messaging. RTP is an Internet-standard protocol for the transport of real-time data, including audio and video media. It can be used for media-on-demand as well as interactive services such as Internet telephony. RTP consists of a data and a control part. The latter is called Real Time Control Part (RTCP).
Currently when using PoC, there is no indication to the talking user of the quality of the outgoing voice burst. The talking user thinks his voice being received properly, until he receives a response from the listening user. Since only one user can speak at a time, there is no way of confirming the quality of service of the system until the user releases the channel and the listener replies. Even a minor degradation of network bandwidth can cause voice quality issues. The methods of the present invention involve restructuring voice data packets in such a way as to minimize the impact of this degradation. For most companies trying to implement 3GPP/3GPP2 based voice application requirements on handsets, voice quality can be enhanced by this mechanism.
PoC may be implemented over a variety of access networks, including GPRS according to 3GPP Release 97/98, EGPRS according to 3GPP Release 99 or later releases, and UMTS according to Release 99 or later releases. For these networks, a PoC implementation preferably follows these recommendations:                The PoC implementation should work in an access network that delivers a throughput of 7.2 kbps or more.        The QoS (Quality of Service) profile parameters should be set such that the Radio Link Control (RLC) uses an acknowledged mode of operation.        If streaming traffic class is supported by the access network, PoC should use this traffic class for the exchange of RTP/RTCP data.        The POC client should support Adaptive Multi Rate (AMR) 5.15 as the mandatory and default CODEC, with optional support of AMR 4.75 being desirable. The support of any other AMR CODEC is at design discretion.        The AMR payload format should use the octet-aligned mode (byte aligned) without interleaving and without CRCs.        
If traffic class streaming can be supported in the GPRS network, then an interactive traffic class Packet Data Protocol (PDP) context is preferably used for SIP and HTTP signaling; and a streaming traffic class PDP context is preferably used for the RTP/RTCP packets. If streaming is not available, then either two interactive PDP contexts may be used (one interactive PDP context intended for PoC signaling and one interactive PDP context for RTP media), or a single PDP context may be used for both PoC signaling and RTP media.
In order to ensure optimal service quality for PoC in GPRS networks, the QoS profile parameter values are carefully selected by the user equipment (UE) in PDP context activation requests. Since 3GPP Release 97/98 compliant networks do not provide support for a streaming traffic class, a QoS profile of a single PDP context may be shared between PoC signaling and media flows.
If using a dedicated PDP context for RTP/RTCP media, this context should be set up before or at the time of the first talk session. The RTCP traffic may be transported on the same PDP context as the SIP/HTTP signaling.
When a single PDP context is shared between media and signaling, PoC proposes some QoS parameter settings that express a compromise between satisfying different transport requirements of signaling and voice media flows to ensure the best possible overall service quality for PoC. But using traffic class streaming does not fully solve the problem. The GPRS network cannot differentiate among the various types of frames within RTP packets and the stability of multiple streams cannot be guaranteed. Also, actual bandwidth in the GPRS network can fluctuate, making scheduling and prioritization of packets important to ensure a good user experience.
Since even the best GPRS network is not able to guarantee any throughput to the UE, the PoC service quality can only be ensured if the radio access network is appropriately dimensioned. The following configurative means are available to improve the performance of the PoC service:
Radio channels can be assigned exclusively to PS data traffic (to avoid pre-emption by CS flows).
The maximal number of PS users multiplexed on the same timeslot (separate for UL and DL) can be limited.
The weight assigned to the priority level (related to the Precedence Class parameter value) of the PoC flow can be augmented.
UDP/IP header compression (RFC2507) can be configured to reduce the required radio link capacity.
If the underlying access network supports traffic class streaming, the secondary PDP context is to be used for the media (voice) flows of the PoC application. In addition, the following configurative means are available to improve the performance of the PoC service:                UDP/IP header compression (RFC2507) or RTP/UDP/IP header compression (RFC3095) can be configured to reduce the required radio link capacity.        Delayed release of DL Temporary Block Flows (TBFs) and Extended TBF Mode in UL (available for 3GPP Release 4 compliant networks only) can be configured to preserve the TBF over a longer period of time.        
PoC is discussed in greater detail in the following technical specifications which are incorporated by reference: PoC, Architecture, PoC Release 2.0, V2.0.8 (2004-06); PoC, Signaling Flows—UE to Network Interface (UNI), PoC Release 2.0, V2.0.6 (2004-06); and PoC User Plane, Transport Protocols, PoC Release 2.0, V2.0.8 (2004-06). Of note, Release 1.0 is also available from the PoC Consortium as well as an upcoming PoC standard from Open Mobile Alliance (OMA).
In summary, where PTT applications operate in a limited bandwidth environment such as cellular networks, voice quality is diminished resulting in a poor user experience regardless of the type of packet compression in use. The present invention addresses this problem.